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DETAILED ACTION 
Response to Amendment 

1 . In'the reply filed on 1 1/8/2007, the following has occurred: 
• Claim 1 is amended. 

Claim Rejections - 35 USC § 103 

2. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

3. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1 , 148 
USPQ 459 (1966), that are applied for establishing a background for determining 
obviousness under 35 U.S.C. 103(a) are summarized as follows: 

1 . Determining the scope and contents of the prior art. 

2. Ascertaining the differences between the prior art and the claims at issue. 

3. Resolving the level of ordinary skill in the pertinent art. 

4. Considering objective evidence present in the application indicating 
obviousness or nonobviousness. 

4. Claims 1, 2, 3, and 4 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Dorenbosch et al. (US PGPUB 20040028009) in view of Oishi (US PGPUB 
20020154624) and VIP: A protocol providing Host Mobility (Communications of the 
ACM, August 1994). 

Regarding claim 1 , Dorenbosch teaches during a handoff process, the 
application on the mobile station continues to use the original gateway address as the 
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primary SCTP address (at a level above a network level) and the gateway continues to 
use the original mobile address as the primary destination address (without varying the 
IP address of the mobile node used by the corresponding node the mobile node moves 
intra-domain or inter-domain). SCTP is the transport layer protocol that is a level above 
network layer. Dorenbosch further teaches in Fig. 2 the mobile station B must also get 
the first IP address, IP A1, to be used by the gateway (identifying a mobile node to a 
corresponding node, with which the mobile node communicates). Address IP A1 can be 
globally unique. It can even be equal to address Y1 , in which case the mobile station 
needs to obtain only one address. The mobile station preferably obtains a private IP 
address, IP A1 that is local to the cellular system. In that case the gateway provides 
Network Address Translation between address Y1 and A1 (identifying the mobile to a 
network address translation (NAT) device at a network interface level using a routable 
actual IP address of the host; and mapping the actual IP address to the original gateway 
IP address). NAT is known and far from trivial, because numerous applications embed 
raw IP addresses in the data they exchange with peers. In such cases address 
translation involves the substitution of address values in application-specific data. This 
type of operation is also known. A gateway that does this type of translation is often 
called an Application Level Gateway (a rule for mapping) (See Paragraph 26 and 45, 
Dorenbosch). 

However, Dorenbosch does not expressly teach changing the actual IP address 
of the host used by the NAT device and and mapping the actual IP address to the virtual 
IP address. Oishi teaches a translator makes a translation rule for associating a new 
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care-of-address with a virtual destination IP address (changing the actual IP address of 
the host used by the NAT device and mapping the actual IP address to the virtual IP 
address) (See Fig. 28 and Paragraph 100 Oishi). It would have been obvious for one 
having ordinary skill in the art at the time of the invention was made to change the 
actual IP address of the host used by the NAT device with a virtual IP address in order 
to provide a method of enabling a communication to be continued without any 
interruption even if one or both of terminals move if a protocol translation is necessary 
at a junction of both networks due to a difference between protocols of these networks 
accommodating one and the other terminals (See Paragraph 9 Oishi). 

However, Dorenbosch and Oishi do not expressly teach without varying virtual IP 
address. VIP: A protocol providing Host Mobility teaches in Fig. 9 an example of a VIP 
address of Host:A remains unchanged while a temporary IP address is assigned to the 
host by, say, DHCP. It would have been obvious for one having ordinary skill in the art 
at the time of the invention was made to have invariant virtual IP address in order to 
have scalable to the scale of the network and the total number of mobile the hosts 
(Page 67 Col 2 Line 17 VIP: A protocol providing Host Mobility). 

Regarding claim 2, Dorenbosch, Oishi, VIP: A protocol providing Host Mobility 
teach the limitations of claim 1 as applied above. Dorenbosch teaches the application 
on the mobile station during a handoff process continues to use the original gateway 
address as the primary SCTP address (maintaining a transport level protocol 
connection while the mobile node moves between a first subnet and a second subnet) 
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(See Paragraph 45 Dorenbosch). The gateway will further perform a transport protocol 
translation between SCTP and TCP/UDP (a transport level protocol ) (See Paragraph 
28 Dorenbosch). However, Dorenbosch does not expressly teach using the virtual IP 
address. Oishi teaches as applied to claim 1 above. It would have been obvious for one 
having ordinary skill in the art at the time of the invention was made to use a virtual IP 
address in order to provide a method of enabling a communication to be continued 
without any interruption even if one or both of terminals move if a protocol translation is 
necessary at a junction of both networks due to a difference between protocols of these 
networks accommodating one and the other terminals (See Paragraph 9 Oishi). 

Regarding claim 3, Dorenbosch, Oishi, VIP: A protocol providing Host Mobility 
teach the limitations of claim 1 as applied above. Oishi teaches the message is 
transmitted to the Mobile IP message translation and a process by the input packet 
filtering process (receiving a packet from an application in the mobile node). The Mobile 
IP message translation and the process associates a virtual source IP address with a 
pair of the source IP address and the care of address, makes a translation rule for 
associating the virtual source IP with the source IP address, and retains it in the 
translation table (including the virtual IP address of the mobile node as a source 
address, translating the virtual IP address of the mobile node to the actual IP address of 
the mobile node for use as the source address). Additionally, the Mobile IP message 
translation and process translates the care of address described in the position 
registration message to and transmits it to the terminal. While the current position 
information is described in the payload of the packet in the IPv4 Mobile IP, it is 
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described in the header of the packet in the IPv6 Mobile IP. (transmitting the packet with 
the actual lP address from the mobile node) (see FIG. 22 and Paragraph 98 Oishi). It 
would have been obvious to one having ordinary skill in the art at the time of the 
invention was made to receive a packet from an application in the mobile node including 
the virtual IP address of the mobile node as a source address, translate the virtual IP 
address of the mobile node to the actual IP address of the mobile node for use as the 
source address, and to transmit the packet with the actual IP address from the mobile 
node because the Mobile IP message translation and process performs the format 
translation as well as rewriting the address and then transmits the position registration 
message to the terminal (See Paragraph 98 the route optimization of Oishi). 

Regarding claim 4, Dorenbosch, Oishi, VIP: A protocol providing Host Mobility 
teach the limitations of claim 3 as applied above. Dorenbosch teaches preferably the 
mobile station obtains a private IP address, A1, which is local to the cellular system 
(the actual IP address is a local private address). The gateway provides Network 
Address Translation between address Y1, an external address, and A1 (translating the 
actual IP address of the mobile node to a public IP address; and transmitting the packet 
with the public IP address to the corresponding node, the mobile node and the 
corresponding node being in different domains connected to each other by a public 
network) (See Fig. 1 and Paragraph 26 Dorenbosch). 

Regarding claim 6, Dorenbosch, Oishi, VIP: A protocol providing Host Mobility 
teach the limitations of claim 1 as applied above. Dorenbosch teaches a mobile station 
can roam from one BSS into the next BSS and connect to another AP as a part of the 
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same Extended Services Set (the mobile node and the corresponding node belonging 
to different subnets within a common domain) (See Paragraph 23 Dorenbosch). 
However, Dorenbosch does not teach the transmitted packet having the virtual IP 
address of the mobile node and receiving an incoming packet from the corresponding 
node by way of the NAT device, wherein the NAT device translates a destination 
address of the incoming packet from the virtual IP address of the mobile node to the 
actual IP address of the mobile node. Oishi teaches in Fig. 24 the DNS response packet 
rewritten from the actual destination IP address to the virtual destination IP address s6 
is transmitted to the terminal 41 via the DNS server 23 (See Paragraph 86 Oishi). Oishi 
further teaches the message is transmitted to the Mobile IP message translation and a 
process by the input packet filtering process. The Mobile IP message translation and 
the process associates a virtual source IP address with a pair of the source IP address 
and the care of address, makes a translation rule for associating the virtual source IP 
with the source IP address, and retains it in the translation table (See Paragraph 98 
Oishi). It would have been obvious to one having ordinary skill in the art at the time of 
the invention was made to transmit a packet having the virtual IP address of the mobile 
node and receive an incoming packet from the corresponding node by way of the NAT 
device, wherein the NAT device translates a destination address of the incoming packet 
from the virtual IP address of the mobile node to the actual IP address of the mobile 
node in order to exchange messages at initiating a communication so as to make a 
name resolving request message a clue to generating translation information, a 
correspondence of an IP address, etc. (See Paragraph 5 Oishi). 
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Regarding claim 7, Dorenbosch, Oishi, VIP: A protocol providing Host Mobility 
teach the limitations of claim 6 as applied above. Oishi teaches in terminals T and R in 
Fig 27 a translation rule for associating with a virtual destination IP address (the 
transmitted packet has a destination address that is a virtual IP address of the 
corresponding node), and that the translator treats the virtual source IP address as an 
IPv6 address 16 of the translator to associate r4 with 16 when making a translation rule 
since a packet destined for the terminal 42 from the terminal 41 passes through the 
translator 12 (the packet is transmitted to the corresponding node by way of the NAT 
device, the method further comprising: translating the virtual IP address of the 
corresponding node within the packet to an actual IP address of the corresponding node 
in the NAT device) (See Paragraph 100 Oishi). It would have been obvious to one 
having ordinary skill in the art at the time of the invention was made to transmit a packet 
to the corresponding node by way of the NAT device, translating the virtual IP address 
of the corresponding node within the packet to an actual IP address of the 
corresponding node in the NAT device in order to exchange messages at initiating a 
communication so as to make a name resolving request message a clue to generating 
translation information, a correspondence of an IP address, etc. (See Paragraph 5 
Oishi). 

Regarding claim 8, Dorenbosch, Oishi, VIP: A protocol providing Host Mobility 
teach the limitations of claim 7 as applied above. Dorenbosch does not teach translating 
the source address of the transmitted packet from the actual IP address of the mobile 
node to the virtual IP address of the mobile node, in the NAT device. Oishi teaches in 
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Fig 27 a DNS query from a terminal 42 is transmitted to a DNS server 22 via a DNS 
server 24 since the IP address corresponding to a name T of the terminal 41 is 
associated with a home address t6, that the translator 1 1 thereby makes a translation 
rule for associating t6 with a virtual destination IP address f4, and that the translator 1 1 
treats the virtual source IP address as an IPv6 address 16 of the translator 12 to 
associate r4 with 16 when making a translation rule since a packet destined for the 
terminal 42 from the terminal 41 passes through the translator 12 (See Paragraph 100 
Oishi). It would have been obvious to one having ordinary skill in the art at the time of 
the invention was made to translate the source address of the transmitted packet from 
the actual IP address of the mobile node to the virtual IP address of the mobile node, in 
the NAT device in order to exchange messages at initiating a communication so as to 
make a name resolving request message a clue to generating translation information, a 
correspondence of an IP address, etc. (See Paragraph 5 Oishi). 

Regarding claim 9, Dorenbosch, Oishi, VIP: A protocol providing Host Mobility 
teach the limitations of claim 1 as applied above. Oishi teaches in Fig 17 and 18 a first 
translator within the first translator domain and a second translator within the second 
translator domain are used (using the NAT device within a first NAT domain while the 
mobile node communicates with a first corresponding node in a first connection initiated 
while the mobile node is located in the first NAT domain; and using a second NAT 
device within a second NAT domain as a home agent for the mobile node while the 
mobile node communicates with the first corresponding node or a second 
corresponding node in a second connection initiated while the mobile node is located in 
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the second NAT domain). It would have been obvious for one having ordinary skill in the 
art at the time of the invention was made to use the NAT device within a first NAT 
domain and use a second NAT device within a second NAT domain as a home agent 
for the mobile node while the mobile node communicates with the first corresponding 
node in order to provide a method of enabling a communication to be continued without 
any interruption even if one or both of terminals move if a protocol translation is 
necessary at a junction of both networks due to a difference between protocols of these 
networks accommodating one and the other terminals (See Paragraph 9 Oishi). 

• Regarding claim 10, Dorenbosch, Oishi, VIP: A protocol providing Host Mobility 
teach the limitations of claim 9 as applied above. Dorenbosch does not teach using a 
packet processing rule for processing traffic from the mobile node and the mobile node 
is in the second NAT domain, the packet processing rule being obtained from a device 
in the first NAT domain. Oishi teaches translating formats of IP packets mutually 
between IPv4 and IPv6. For example, they are used for a translation between an IPv4 
address and an IPv6 address. An apparatus for performing this translation is referred to 
as a translator (using a packet processing rule for processing traffic from the mobile 
node) (See Paragraph 3 Oishi). Oishi further teaches in Fig 17 and 18 the translators 
12, 13 and the translation server 23-1 is used for the translation information (the mobile 
node is in the second NAT domain, the packet processing rule being obtained from a 
device in the first NAT domain). It would have been obvious for one having ordinary 
skill in the art at the time of the invention was made to use a packet processing rule for 
processing traffic from the mobile node and the mobile node is in the second NAT 
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domain, and to obtain the packet processing rule from a device in the first NAT domain 
to provide a method of enabling a communication to be continued without any 
interruption even if one or both of terminals move if a protocol translation is necessary 
at a junction of both networks due to a difference between protocols of these networks 
accommodating one and the other terminals (See Paragraph 9 Oishi). 

Regarding claim 11, Dorenbosch, Oishi, VIP: A protocol providing Host Mobility 
teach the limitations of claim 10 as applied above. Dorenbosch does not teach when the 
mobile node moves from the first NAT domain to the second NAT domain, a mobility 
manager in the second NAT device requests and receives the packet processing rule 
from a mobility manager of the first NAT domain, wherein the first and second mobility 
managers have centralized views of users in the first and second NAT domains, 
respectively, and mappings between virtual IP addresses and actual IP addresses of 
the users currently in the first and second NAT domains, respectively Oishi teaches in 
Fig 17 and 18 the DNS server or translation server 23-1 have centralized views of users 
in the first and second translator domains. It would have been obvious for one having 
ordinary skill in the art at the time of the invention was made to provide a method of 
enabling a communication to be continued without any interruption even if one or both 
of terminals move if a protocol translation is necessary at a junction of both networks 
due to a difference between protocols of these networks accommodating one and the 
other terminals (See Paragraph 9 Oishi). 

Regarding claim 12, Dorenbosch, Oishi, VIP: A protocol providing Host Mobility 
teach the limitations of claim 9 as applied above. However, Dorenbosch does not teach 
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the first and second connections partially overlap in time, so that the first and second 
NAT devices act as first and second home agents for the mobile node concurrently. 
Oishi teaches in Fig. 3 a communication route selected if the mobile terminal 42 moves 
from the position q to a position r. The packet destined for the terminal 42 transmitted 
from the terminal 41 reaches the terminal 42 via the translator 13. On the other hand, 
the packet destined for the terminal 41 transmitted from the terminal 42 is transmitted to 
the terminal 41 via the translator 12 and the home agent 31. It would have been obvious 
for one having ordinary skill in the art at the time of the invention was made to overlap in 
time for the first and second connections partially to provide a method of enabling a 
communication to be continued without any interruption even if one or both of terminals 
move if a protocol translation is necessary at a junction of both networks due to a 
difference between protocols of these networks accommodating one and the other 
terminals (See Paragraph 9 Oishi). 

Regarding claim 13, Dorenbosch, Oishi, VIP: A protocol providing Host Mobility 
teaches the limitations of claim 12 as applied above. However, Dorenbosch does not 
teach the mobile node has the same virtual address for both the first and second 
connections. Oishi teaches in Fig. 24-45 making translation rules with virtual IP 
addresses (16, 14 , m6, and m4). Fig. 27 and 28 show the virtual IP address 16 is used 
before and after the movement of terminal with a new care of address (the mobile node 
has the same virtual address for both the first and second connections). It would have 
been obvious for one having ordinary skill in the art at the time of the invention was 
made to have the same virtual address for both the first and second connections to 
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provide a method of enabling a communication to be continued without any interruption 
even if one or both of terminals move if a protocol translation is necessary at a junction 
of both networks due to a difference between protocols of these networks 
accommodating one and the other terminals (See Paragraph 9 Oishi). 

Regarding claim 16, Dorenbosch, Oishi, VIP: A protocol providing Host Mobility 
teach the limitations of claim 12 as applied above. However, Dorenbosch does not 
teach translating the virtual IP address to a public IP address in the NAT device. Oishi 
teaches a DNS server translating from a virtual IP address to an actual IP address 
(translating the virtual IP address to a public IP address in the NAT device) (See 
Paragraph 86 Oishi). It would have been obvious for one having ordinary skill in the art 
at the time of the invention was made to have translating the virtual IP address to a 
public IP address in the NAT device to provide a method of enabling a communication 
to be continued without any interruption even if one or both of terminals move if a 
protocol translation is necessary at a junction of both networks due to a difference 
between protocols of these networks accommodating one and the other terminals (See 
Paragraph 9 Oishi). 

5. Claims 18, 19, 21, and 24 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Oishi et al. (US PGPUB 20020154624) in view of VIP: A protocol 
providing Host Mobility (Communications of the ACM, August 1994). 

Regarding claim 18, Oishi teaches in FIG. 24 a sequence diagram in which the 
IPv6 mobile terminal in the foreign network originates a call, where t6 is an actual IP 
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address and s6 is a virtual IP address (a network layer for transmitting and receiving 
packets; and an intermediate driver that transmits packets to the network layer and 
receives packets from the network layer using a virtual IP address to identify the mobile, 
node the driver transmitting packets to the network interface and receiving packets from 
the network interface using a routable actual IP address to identify the mobile node). 
Oishi further teaches two translators make translation rules for associating a new coa 
with a virtual destination IP address (permits the actual IP address to change when the 
mobile node moves intra-domain or inter-domain) (See Fig. 28 and Paragraphs 99 and 
100 Oishi). However, Oishi does not expressly teach without a corresponding change in 
the virtual IP address. VIP: A protocol providing Host Mobility teaches in Fig. 9 an 
example of a VIP address of Host:A remains unchanged while a temporary IP address 
is assigned to the host by, say, DHCP. It would have been obvious for one having 
ordinary skill in the art at the time of the invention was made to have a mobile node a 
corresponding change in the virtual IP address in order to have scalable to the scale of 
the network and the total number of mobile the hosts (Page 67 Col 2 Line 17 VIP: A 
protocol providing Host Mobility). 

Regarding claim 19, Oishi and VIP: A protocol providing Host Mobility teach the 
limitations of claim 18 as applied above. Oishi teaches the packet formats shown in 
FIGS. 49, 50, and 51 . The terminal 41 transmits the packet to the terminal 42. This 
packet is received by the translator 13 and then transmitted to the data packet 
translation and process 104 shown in FIG. 19. The data packet translation and process 
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104 searches the translation table 101 for the virtual destination IP address s6 as a 
search key (the intermediate driver includes means for changing a source IP address of 
packets transmitted by the mobile node from the virtual address to the actual address) 
(See Fig. 49, 50, 51 and Paragraph 93 Oishi). 

Regarding claim 21, Oishi and VIP: A protocol providing Host Mobility teach the 
limitations of claim 18 as applied above. Oishi teaches in Fig 27 a DNS query from a 
terminal 42 is transmitted to a DNS server 22 via a DNS server 24 since the IP address 
corresponding to a name T of the terminal 41 is associated with a home address t6, that 
the translator 1 1 thereby makes a translation rule for associating t6 with a virtual 
destination IP address f4, and that the translator 1 1 treats the virtual source IP address 
as an IPv6 address 16 of the translator 12 to associate r4 with 16 when making a 
translation rule since a packet destined for the terminal 42 from the terminal 41 passes 
through the translator 12 (changing a destination IP address of packets received by the 
mobile node from the actual address to the virtual address) (See Paragraph 100 Oishi). 

Regarding claim 24, Oishi and VIP: A protocol providing Host Mobility teach the 
limitations of claim 18 as applied above. Oishi teaches Oishi teaches in FIG. 24 a 
mobile IP client that transmits and receives packets by way of the network layer, the 
intermediate driver and the network interface. 

6. Claim 5 is rejected under 35 U.S.C. 103(a) as being unpatentable over 
Dorenbosch (US PGPUB 20040028009) and modified by Oishi (US PGPUB 
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20020154624) as applied to claim 4 above, and further in view of Leung (US Patent 
6487605, hereinafter Leung). 

Regarding claim 5, Dorenbosch and Oishi teach the limitations of claim 1 as 
applied above. Dorenbosch teaches packet data communication from one IP connection 
to another (receiving an incoming packet) (See Paragraph 12 Dorenbosch). One of the 
common element to switch between any two IP transport media is to route traffic 
through an Application Level Gateway that translates (from the corresponding node Tn 
the NAT device) between SCTP and TCP/UDP. Dorenbosch further teaches the 
gateway provides Network Address Translation between address Y1 and A1 where Y1 
is an external IP address and A1 is a private IP address (the incoming packet having 
the public IP address as a destination; a first translating step of translating the public IP 
address to the actual IP address of the mobile node, the first translating step being 
performed in the NAT device) (See Paragraph 26 and 36 Dorenbosch). However, 
Dorenbosch and Oishi do not expressly teach a second translating step of translating 
the actual IP address of the mobile node to the virtual IP address of the mobile node, 
the second translating step being performed in the mobile node. Inoue teaches the 
Address Mapping Table information of a mobile host indicating a correspondence 
between a virtual IP address and an actual IP address of a mobile host is transferred 
according to the need so that an information for routing up to the mobile host is 
sequentially updated (See Fig. 12 and Col. 14 Lines 29-38 Inoue). It would have been 
obvious to one having ordinary skill in the art at the time of the invention was made to 
translate the actual IP address of the mobile node to the virtual IP address of the mobile 



Application/Control Number: Page 17 

10/618,880 

Art Unit: 2619 

node and the step being performed in the mobile node in order to be capable of 
realizing flexible address control and management for the mobile computer (See 
Abstract Inoue). 

7. Claim 14 is rejected under 35 U.S.C. 103(a) as being unpatentable over 
Dorenbosch (US PGPUB 20040028009) and modified by Oishi (US PGPUB 
20020154624) as applied to claim 12 above, and further in view of Rezaiifar (US 
PGPUB 20040085931 , hereinafter Rezaiifar). 

Regarding claim 14, Dorenbosch and Oishi teach the limitations of claim 12 as 
applied above. Oishi teaches in Fig. 27, 28, and 29 the virtual IP address 16 is used 
before and after the movement of terminal with the new coa q6 with a route 
optimization. The translation rule has rules for 16 (a first virtual address) and q6(a 
second virtual address) in Fig 29 (continuing to use the first virtual address for 
connections initiated by the mobile node using the first virtual address, the continuing 
use of the first virtual address being concurrent with use of the second virtual address 
for connections initiated after the second virtual address is assigned to the mobile 
node). However, Dorenbosch and Oishi do not expressly teach an additional node in the 
second NAT domain has the same virtual address as the mobile node and assigning a 
second virtual address to the mobile node for connections initiated after the mobile node 
moves to the second domain. Rezaiifar, in the same field of endeavor, teaches the 
PDSNs in a mixed network are modified to prevent having the same IP address 
assigned to two different R-P sessions. Any time the FA assigns an IP address to an 
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IMSI, the FA purges its tables of any other entries bearing the same IP address, 
regardless of the value of the IMSI. Only one R-P session per IP address is allowed 
within an FA of a PDSN (See Paragraph 63 and 64 Rezaiifar). It would have been 
obvious to one having ordinary skill in the art at the time of the invention was made to 
assign a second virtual address to the mobile node for connections initiated after the 
mobile node moves to the second domain when an additional node in the second NAT 
domain has the same virtual address as the mobile node otherwise it would be unable 
to unambiguously route the packet to a RAN (See Paragraph 63 Rezaiifar). 

8. Claims 15 and 17 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Dorenbosch (US PGPUB 20040028009) and modified by Oishi (US PGPUB 
20020154624) as applied to claim 1 above, and further in view of Su (US PGPUB 
20030172142, hereinafter Su). 

Regarding claim 15, Dorenbosch and Oishi teach the limitations of claim 1 as 
applied above. Oishi teaches a DNS server translating from a virtual IP address to an 
actual IP address. However, Dorenbosch and Oishi do not expressly teach assigning 
the virtual and actual IP addresses using Dynamic Host Configuration Protocol. Su, in 
the same field of endeavor, teaches setting up the DHCP server, a step is firstly to 
install a WINDOWS server in a computer having NIC in three pieces, in which the first 
piece is an Ethernet card having a legal IP; the second piece is also an Ethernet card 
having a virtual IP address; and the third piece is a wireless-LAN card having "a virtual 
IP address (See Paragraph 33 Su). It would have been obvious to one having ordinary 
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skill in the art at the time of the invention was made to assigning the virtual and actual 
IP addresses using Dynamic Host Configuration Protocol because the IP address of 
every subscriber computer is set obtainable automatically, therefore the DNS could be 
set on the DNS server provided by an ISP (See Paragraph 36 Su). 

Regarding claim 17, Dorenbosch and Oishi teach the limitations of claim 1 as 
applied above. However, Dorenbosch and Oishi do not expressly teach dividing an 
available range of private IP addresses into a first range to be used for actual IP 
addresses and a second range to be used for virtual IP addresses. Su teaches setting 
up a DHCP server for splitting individual private IP address such that a plurality of IP 
addresses is provided to the respective Ethernet and wireless-LAN, and a dynamic IP 
address (virtual IP addresses) is assigned to every subscriber end (See Paragraph 24 
Su). It would have been obvious to one having ordinary skill in the art at the time of the 
invention was made to divide an available range of private IP addresses into a first 
range to be used for actual IP addresses and a second range to be used for virtual IP 
addresses because the dynamic IP address is set obtainable automatically (See 
Paragraph 24 Su). 

9. Claim 20 is rejected under 35 U.S.C. 103(a) as being unpatentable over Oishi 
(US PGPUB 20020154624) modified by VIP: A protocol providing Host Mobility as 
applied to claim 18 above, and further in view of Gillies et al. (US PGPUB 
20030212821, hereinafter Gillies). 
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Regarding claim 20, Oishi and VIP: A protocol providing Host Mobility teache the 
limitations of claim 18 as applied above. However, Oishi does not expressly teach 
encapsulating packets transmitted by the mobile node. Gillies, in the same field of 
endeavor, teaches an example encapsulated communication packet and the set of 
hierarchical communication packets includes a MAC layer message frame, an attribute 
routing system message frame, an IP layer message frame, and a TCP layer message 
frame (See Fig. 4 and Paragraph 72 Gillies). It would have been obvious to one having 
ordinary skill in the art at the time of the invention was made to encapsulate packets 
transmitted by the mobile node in order to preferably allow for the message frame to be 
validated and verified as delivered intact, as is well understood in the art (See 
Paragraph 73 Gillies). 

10. Claims 22 and 23 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Oishi (US PGPUB 20020154624) modified by VIP: A protocol providing Host 
Mobility as applied to claim 18 above, and further in view of Su (US PGPUB 
20030172142, hereinafter Su). 

Regarding claim 22, Oishi and VIP: A protocol providing Host Mobility teache the 
limitations of claim 18 as applied above. Oishi teaches in Fig. 24 a sequence diagram in 
which the IPv6 mobile terminal in the foreign network originates a call. S6 is a virtual IP 
address and t6 is an actual IP address (requesting and receiving from a server the 
virtual IP address and the actual IP address upon startup of the mobile node)(See Fig. 
24 Oishi). However, Oishi does not expressly teach dynamic host configuration protocol 
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(DHCP). Su, in the same field of endeavor, teaches setting up the DHCP server, a step 
is firstly to install a WINDOWS server in a computer having NIC in three pieces, in 
which the first piece is an Ethernet card having a legal IP; the second piece is also an 
Ethernet card having a virtual IP address; and the third piece is a wireless-LAN card 
having a virtual IP address (See Paragraph 33 Su). It would have been obvious to one 
having ordinary skill in the art at the time of the invention was made to assigning the 
virtual and actual IP addresses using Dynamic Host Configuration Protocol because the 
IP address of every subscriber computer is set obtainable automatically, therefore the 
DNS could be set on the DNS server provided by an ISP (See Paragraph 36 Su). 

Regarding claim 23, Oishi, VIP: A protocol providing Host Mobility , and Su teach 
the limitations for claim 22 as applied above. Oishi teaches in Fig. 25 new coa q6 is 
associated with the virtual IP address S6 after the movement of terminal T (transmitting 
the virtual IP address a server when the mobile node moves to the second subnet, to 
allow a new actual IP address to be associated with the virtual IP address) (See Fig. 25 
Oishi). However, Oishi does not expressly teach dynamic host configuration protocol 
(DHCP). Su, in the same field of endeavor, teaches setting up the DHCP server, a step 
is firstly to install a WINDOWS server in a computer having NIC in three pieces, in 
which the first piece is an Ethernet card having a legal IP; the second piece is also an 
Ethernet card having a virtual IP address; and the third piece is a wireless-LAN card 
having a virtual IP address (See Paragraph 33 Su). It would have been obvious to one 
having ordinary skill in the art at the time of the invention was made to assigning the 
virtual and actual IP addresses using Dynamic Host Configuration Protocol because the 
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IP address of every subscriber computer is set obtainable automatically, therefore the 
DNS could be set on the DNS server provided by an ISP (See Paragraph 36 Su). 

Response to Arguments 

11. Applicant's arguments, see Page 12 Line 15, Page 13 Line 9, and Page 15 Line 
5, filed 1 1/8/2007, with respect to the rejection(s) of claim(s) 1-24 under 35 

U.S.C. 103(a) have been fully considered and are persuasive. Therefore, the rejection 
has been withdrawn. However, upon further consideration, a new ground(s) of rejection 
is made in view of VIP: A protocol providing Host Mobility (Communications of the ACM, 
August 1994). 

Conclusion 

12. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Eunsook Choi whose telephone number is 571-270- 
1822. The examiner can normally be reached on Monday-Friday 8:00-5:00 EST. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Chau Nguyen can be reached on 571-272-3126. The fax phone number for 
the organization where this application or proceeding is assigned is 571-273-8300. 



Application/Control Number: 



Page 23 



10/618,880 
Art Unit: 2619 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

Eunsook Choi 
1/11/2008 
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